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Health and Safety 


Attention is drawn to the Health and Safety at Work, etc Act 1974 as amended by the 
Consumer Protection Act 1987. 

All installation, operation, maintenance, repair and testing related to any equipment 
referenced in this document shall be based upon adequate safety procedures including, but 
not limited to, safely designed and regularly maintained ancillary equipment. 

Written instructions based upon this document shall contain warnings in respect of all 
potential hazards, where applicable. 


PROTECT-COMMERCIAL 




PROTECT-COMMERCIAL 


trustedborders 


Document Ref: EB-RP-01256 
Issue Number: 4.0 
Date of Issue: 01 September 2009 
Page 4 of 39 


Contents 

1 Introduction. 

1.1 Definitions. 

1.2 Document Updates. 

1.3 References. 

1.4 Structure. 

2 POLICY QUESTIONS. 

2.1 Purpose. 

2.2 Data Submission. 

2.3 Data Timings. 

2.4 Aircraft Leasing. 

2.5 Reporting Metrics. 

2.6 The Common Travel Area & Domestic Travel. 

2.7 Maritime Issues. 

2.8 Data Protection. 

2.9 e-Borders Alerts to UK Border Agencies on Passengers/Crew 

3 BUSINESS PROCESS QUESTIONS. 

3.1 Crew Questions. 

3.2 Departure Messages. 

3.3 Transit and Through-Checked Passengers. 

3.4 Short Notice & Charter Operations. 

3.5 Multi-Leg Journeys. 

3.6 Diversions, Delays & Cancellations. 

3.7 System Outages. 

3.8 Connectivity. 

4 TECHNICAL QUESTIONS. 

4.2 Unique Identifiers. 

4.3 Batch and Multi-Part Messages. 

4.4 Miscellaneous. 

A1 Change Record. 


Figures 

Figure 1 - Individual Messaging - Passenger. 

Figure 2 - Batch Messaging - Passenger. 

Figure 3 - Individual Messaging - Crew. 

Figure 4 - Batch Messaging - Crew. 

Figure 5 - Post Departure Information. 

Figure 6 - Multiple Voyages on a Multi-Leg Flight. 

Figure 7 - Multiple Leg Inbound Flight. 

Figure 8 - Multiple Leg Flight Transiting the UK. 

Figure 9 -Transit Flight - Inbound Voyage Reporting. 

Figure 10 - Transit Flight - Outbound Voyage Reporting (Case 1) 
Figure 11 - Transit Flight - Outbound Voyage Reporting (Case 2) 

Tables 

Table 1 - Acronyms and Abbreviations. 

Table 2 - References. 


..5 

..5 

..6 

..6 

..7 

..8 

..8 

..8 

10 

17 

17 

18 

19 

20 
21 

21 

21 

22 

23 

23 

24 
30 
33 

33 

34 

35 
37 
37 
39 


11 

12 

12 

13 

14 
25 

25 

26 
27 
27 
27 


5 

6 


PROTECT-COMMERCIAL 
















































PROTECT-COMMERCIAL 


trustedborders 


Document Ref: EB-RP-01256 
Issue Number: 4.0 
Date of Issue: 01 September 2009 
Page 5 of 39 


INTRODUCTION 

Trusted Borders has created this document in response to questions that are frequently 
asked by Carriers and third party agents such as suppliers of DCS and GDS. This 
document will be updated in response to subsequent questions that arise and which 
merit inclusion. 

Definitions 

In this document, unless the context otherwise requires, the following terms are defined 
as set out below: 


Table 1 - Acronyms and Abbreviations 


Term 

Definition 

ACCWG 

Air Carrier Connectivity Working Group 

AOC 

Aircraft Operators Certificate 

ARINC 

Aeronautical Radio, Inc 

CRS 

Computerised Reservation System 

CESG 

Communications-Electronics Security Group 

CTA 

Common Travel Area 

DCS 

Departure Control System 

DTI 

Domestic Travel Information 

FAQ 

Frequenty Asked Questions 

GDS 

Global Distribution System 

GHA 

Ground Handling Agent 

IATA 

International Air Transport Association 

ICAO 

International Civil Aviation Organization 

ICD 

Interface Control Document 

JBOC 

Joint Border Operations Centre (now the NBTC) 

MCCWG 

Maritime Carrier Connectivity Working Group 

MOD 

Ministry of Defence 

MRTD 

Machine Readable Travel Document 

MRZ 

Machine Readable Zone 

NBTC 

National Border Targeting Centre (formerly the JBOC) 

OPI 

Other Passenger Information 

PNR 

Passenger Name Record 

SI 

Service Information 
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Term 

Definition 

SITA 

Societe Internationale de Telecommunications Aeronautiques 

STA 

Scheduled Time of Arrival (aviation industry standard abbreviation) 

STD 

Scheduled Time of Departure (aviation industry standard abbreviation) 

STT 

Specific Transport Type 

TDI 

Travel Document Information 

TDN/IS 

Travel Document Number/Issuing State 

UK 

United Kingdom 

UKBA 

United Kingdom Border Agency 

UN/EDIFACT 

United Nations/EDI for Administration, Commerce and Trade 

VRM 

Vehicle Registration Mark 

WCO 

World Customs Organisation 


1.2 Document Updates 

Updates to this document will occur through two mechanisms: 

• As more Carriers establish interfaces with e-Borders, additional questions are likely to 
be asked. As appropriate, the most frequently asked of these questions will be 
incorporated into this document. 

• Initially, e-Borders will support collection of Travel Document Information (TDI) and 
Service Information (SI) over a variety of interface types. Data collection of Other 
Passenger Information (OPI), Domestic travel Information (DTI) and Specific Transport 
Type (STT) data will be added at a later date. FAQs to cover collection of this data will 
be added as and when required. 


1.3 References 


Table 2 - References 


ID 

Document Number 

Document Name 

Version 

A 

EB-SD-00851 

e-Borders Generic Carrier ICD 

6.0 

B 

EB-SD-00614 

e-Borders Carrier ICD for PAXLIST TDI-SI 
(Annex) 

7.0 

C 

EB-SD-00655 

e-Borders Carrier ICD for e-NOAD-XML TDI- 
VRM-SI (Annex) 

6.0 
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Structure 

This document comprises four sections: 

Section 1 Introduction 
Section 2 Policy Questions 

Questions concerning policy issues related to the e-Borders system. 
Responses in this section are provided by the UKBA. 

Section 3 Business Process Questions 

Questions concerning business processes. How, when and where should 
and/or can data be submitted to e-Borders. 

Section 4 Technical Questions 

Questions concerning matters such as message formats and transmission 
methods for transferring data to e-Borders. 
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POLICY QUESTIONS 

Responses in this section have been provided by the UK Border Agency (UKBA). 

Purpose 

e-Borders is a key component of the Government’s border technology programme, 
aiming to make the UK safer and speeding up travel for legitimate travellers. The 
Programme aims to deliver a modern border control which is more secure, effective and 
efficient. 

The purpose of e-Borders is to collect and analyse passenger, service and crew data 
provided by carriers (air, sea and rail), in respect of all journeys to and from the United 
Kingdom in advance of travel, supporting an intelligence-led approach to operating 
border controls. 

e-Borders will improve the security, efficiency and effectiveness of the border. It will, in 
particular: 

• be capable of processing rapidly increasing numbers of travellers; 

• increasingly make legitimate travel easier, along with use of other technology 
such as biometric passports, iris and facial recognition systems; 

• keep out or monitor individuals that could cause harm; 

• maintain a comprehensive travel history allowing the UKBA to know who has 
travelled to the UK, whether as crew or passenger, and when they left; and 

• help the UKBA and police to target resources more effectively. 

Further information about the e-Borders programme is available at: 
http://www.ukba.homeoffice.gov.uk/travellingtotheuk/beforetravel/advanceinfopassengers/ 


Data Submission 


Question: Why do we need to submit data to e-Borders? 

Answer: In order to achieve the aims and objectives of e-Borders the UK government 
has passed legislation that requires Carriers "arriving or expected to arrive in the UK" or 
"leaving or expected to leave the UK" to submit data to e-Borders. 

An overview of the legislation may be found at: 

http://www.ukba.homeoffice.gov.uk/travellingtotheuk/beforetravel/advanceinfopassengers/ 

The statutory order may be found at: 
http://www.opsi.gov.uk/si/si2008/pdf/uksi 20080005 en.pdf 


Question: What data needs to be submitted? 


Answer: Pre-departure and post-departure information is required for each passenger 
and member of crew on the voyage. 

• Pre-departure information - provides the NBTC with sufficient time to process the 
data for each passenger and member of crew prior to STD. This allows for an early 
alert to be raised and subsequently a timely intervention by the appropriate agency 
where required. This message consists of Service Information (see tables 6-8 in 
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reference A) and Travel Document Information (see table 9 in reference A). Pre¬ 
departure information can be provided in the following ways. 

• Individual messaging per passenger or crew member; this supports more 
timely operational interventions and better positions the Carrier for any authority 
to carry scheme which may be introduced in the future. 

• Batched submission of passenger or crew data; which could constitute a 
single pre-departure batch, multiple batches or a combination of batch and 
individual messages. 

• Departure information - provides the NBTC with final confirmation of the passengers 
and members of crew either inbound or outbound, to or from the UK. Exactly one (1) 
post-departure message must be submitted for a voyage, when the message contains 
traveller records for both passengers and crew. Where messages contain only crew or 
passenger records by design (PAXLST) or choice (e.g. Excel), then exactly one (1) 
passenger and one (1) crew post-departure message must be submitted. These 
messages must contain the same SI data as the pre-departure messages. The identity 
of those on board must be indicated by using one of the following three message 
types. Where messages contain only crew or passenger records, it is not necessary to 
use the same message type for submitting crew data as is used for submitting 
passenger data. 

• Departure Confirmation; A Departure Confirmation message identifies all 
travellers (crew, passenger or both) on board. As a minimum TDN/IS must be 
reported for each traveller. 

• Departure Exception (not on board); A Departure Exception message identifies 
all travellers (crew, passenger or both) for whom a pre-departure record was sent 
but who did not depart on the voyage. As a minimum TDN/IS must be reported 
for each traveller. 

• Departure Exception (nil return); A Departure Exception (DE) nil return 
message confirms that all travellers for whom a pre-departure record was sent 
departed on the voyage. A nil return message is identified by the fact that it 
contains no traveller records. Caution should be taken when submitting a DE (nil 
return) in any format other than PAXLST as this will automatically be taken as 
being for both passengers and crew. 


Question: We carry a variety of VIPs; Heads of State, Royal family 
members amongst others, for whom security is paramount and for 
whom we are not provided with all TDI. How do we report these 
individuals? 


Answer: The UK authorities require that TDI must be provided for all passengers without 
exception. 


Question: The crew operating our service into the UK do not carry 
their passports as they do not leave the aircraft. Is this a problem 
and, if so, what documents should they carry? 

Answer: Crew must carry either a valid passport, a pilot's licence or a crew member 
certificate. All documents must contain a description of the holder, including nationality 
and photograph. This will be dealt with in a practical and pragmatic manner as it is today. 
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Question: What is the threshold of carrier readiness needed before a 
country can go live? That is, what percentage of the carriers 
operating into or out of country X need to be certified and ready to 
go live before a go-live date is issued? 


Answer: The UKBA has given an undertaking that they will work towards 100% of 
carriers and volume for a particular country before requiring data to be reported. It may 
not always be possible to achieve this outcome and the Agency therefore reserves the 
right to require go-live for a particular country despite not having reached full coverage. 


Data Timings 

Question: When does the data need to be submitted? 

There are different timelines for the pre-departure message depending upon whether the 
message is for passenger or crew data. See the explanation below. 


Pre-Departure Information 

Passenger Data - Individual Messaging 

1) Passenger data can be sent via individual messages from -24hrs STD until Flight 
Close; i.e. until no more passengers can board the plane. Passenger pre-departure 
data cannot be provided earlier than STD -24hrs. 

2) To support operational interventions, it is expected that individual messages will be 
sent only once all TDI elements are known for that individual (messages with missing 
data elements are not wanted). The vast majority of individual messages are 
expected by STD -30mins. 

3) It is accepted that some individual messages may be received beyond STD -30mins, 
especially where Flight Close does not take place until much closer to STD (or Push 
Back where a delay has been experienced). 

4) TDI and SI will need to be sent for each individual pre-departure message. 


Please note: Carriers need to consider the operational impact of late interventions 

by agencies if they provide individual messages beyond STD -30mins. 
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2.3.2.2 Passenger Data - Batch Messaging 

1) Passenger data can be sent via batch messages from -24hrs STD until Flight Close; 
i.e. until no more passengers can board the plane. Passenger pre-departure data 
cannot be provided earlier than STD -24hrs. 

2) The Authority expect that TDI will only be sent once all TDI elements are known 
(messages with missing data elements are not wanted). 

3) To support operational interventions, it is expected that a single (or number of) batch 
message(s) is provided such that the latest information has been provided by STD - 
30mins. This is expected to cover the vast majority of passengers expecting to 
travel. 

4) Carriers are encouraged to provide batch drops earlier than STD -30mins to provide 
information as early as possible, thereby minimising the impact of late interventions 
by agencies on their own operations. 

5) It is accepted that some passengers may join the flight beyond STD -30mins, 
especially where Flight Close does not take place until much closer to STD (or push 
back where a delay has been experienced). Where this happens a Carrier may 
provide either: 

(a) a single batch covering all additional passengers since STD -30mins OR 

(b) multiple batches as additional passengers become known. 

The Authority has a strong preference for b). Under either scenario, the later the 

data is submitted, the greater the risk to Carriers of operational impact from late 

interventions by agencies on outbound flights from the UK. 
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Figure 2 - Batch Messaging - Passenger 


2.3.2.3 Crew Data - Individual Messaging 

1) Crew data can be sent via individual messages from -48hrs STD until the point at 
which no further changes are possible. Crew pre-departure data cannot be provided 
earlier than STD -48hrs. 

2) It is expected that all TDI will only be sent once all TDI elements are known for the 
Crew member (Messages with missing data elements are not wanted). 

3) To support operational interventions, it is expected that the vast majority of Crew 
individual messages are sent by STD -60mins. 

4) It is accepted that some crew changes may take place beyond STD -60mins (and up 
to push back in the case of a delay). When this happens, TDI for the new crew 
members should be provided as soon as it is known. 


Please note: Carriers need to consider the operational impact of late interventions by agencies 

if they provide Individual Messages beyond STD -60mins. 
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Figure 3 - Individual Messaging - Crew 
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2.3.2.4 Crew Data - Batch Messaging 

The same principles apply as with Batch Messaging for Passengers. The following key 
differences are highlighted: 

1) Crew data cannot be provided earlier than STD -48hrs (rather than -24hrs for 
passengers). 

2) The vast majority of Batch Messages are expected by STD -60mins for Crew (rather 
than -30mins for passengers). 

3) It is accepted that some crew changes may take place beyond STD -60mins (and up 
to push back in the case of a delay). When this happens a Carrier can provide 
either: 

a) A single batch covering all additional crew since STD -60mins OR 

b) Multiple batches as additional crew become known. 


The Authority has a strong preference for b). Under either scenario, the later the 

data is submitted, the greater the risk to Carriers of operational impact from late 

interventions by agencies on outbound flights from the UK. 
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Figure 4 - Batch Messaging - Crew 
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Post-Departure Information 

The timings for Post-Departure Information are the same for both Passenger and Crew 
information, regardless of whether an individual or batch message solution was used 
pre-departure. 



Question: If a Carrier has finished transmitting all passenger check¬ 
in messages 30 minutes prior to departure, and are then cleared to 
depart early, are they permitted to leave? 


Answer: If all checked-ln and connecting passengers have boarded within the 30-minute 
window, the Carrier is not required to wait 30 minutes from the time the data is 
transmitted prior to secure the vessel/train/aircraft and departing. The requirement is to 
transmit the data 30 minutes prior to the STD; it is understood the actual departure time 
may vary. The post-departure message must be transmitted within 30 minutes of actual 
push-back, not the original expected push-back time. 


Question: Can a Carrier transmit data prior to 48 hours before 
departure, say up to 14 days before for round trips such as a charter 
and/or package holiday? 


Answer: No. The window for submission is as defined in Reference A and re-iterated in 
this document. 


Question: Collation and transmission of departure data is difficult at 
some remote locations, both for infrastructure and other reasons, 
and must be sent from off-site. In such circumstances, can the post¬ 
departure message be sent outside the 30 minute window? 

Answer: A Departure message (either departure confirmation or departure exception) is 
required to be sent inside the required time window. If, for insurmountable reasons the 
message does not become available in time, the message may be transmitted outside 
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the window, if necessary. The timing of each Carrier's data submission to e-Borders will 
be monitored and reported as part of e-Borders data quality monitoring function. 

If it is considered that the infrastructure or other factors at a location make reporting 
within the normal time window impractical, carriers may submit a request for an 
adjustment to the time window, including all relevant details. 


Question: Can a passenger check-in message be sent later than 30 
minutes before departure? 

Answer: All check-in data that is available must be submitted no later than 30 minutes 
before scheduled departure. It is accepted that some passengers may join a flight later 
than 30 minutes before scheduled departure, especially where Flight Close does not 
take place until much closer to departure time (or Push Back where a delay has been 
experienced). Where this applies, pre-departure data is also required for the late arriving 
passengers. It is the strong preference of the agencies for Carriers to configure their 
systems so that details for the late passengers are sent in real time as soon as these 
become known. However, Carriers are also permitted to store up late arrivals and 
submit them in a single, second pre-departure data batch at flight close. Clearly, under 
either scenario, the later the data is submitted, the greater the risk of operational impact 
from late interventions by agencies on outbound flights from the UK. 


Question: Can a passenger be included in a Departure message 
when they have not been included in a previous check-in message? 

Answer: The correct procedure is that a check-in message should be sent under all 
circumstances, even if it is late. Departure messages containing passengers not 
previously reported in a corresponding check-in message will be monitored and reported 
as part of e-Borders data quality monitoring. 


Question: We have some hubs where late notice crew changes can 
take place which are not passed to our main base for incorporation 
into the crew system until after the flight has departed and the 
departure message sent. Are we required to report such changes, 
and if, how? 

Answer: All crew changes that are submitted prior to the departure message being sent 
must be reported. If changes are regularly submitted after the departure message has 
been sent, carriers should consider requesting an extension to the submission window to 
allow their incorporation. The timing and accuracy of each Carrier's data submission to 
e-Borders will be monitored and reported as part of e-Borders data quality monitoring. 


Question: For crew data, our system only receives notification of 
take-off time from the aircraft, not push-back. Can we use this as the 
trigger for the sending of the post-departure message instead? 

Answer: Yes. The UKBA is aware of the issues and problems involved and, where 
push-back time is not available, take-off time may be used as a substitute. 
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Question: Service Information includes Scheduled Time of Departure 
(STD) and Scheduled Time of Arrival (STA). Our departure and 
arrival times can vary according to which system is used as the data 
source. Which times should be reported? 

Answer: The STD and STA to be reported are to be those reported by the Computerised 
Reservation System (CRS) selected by the Carrier as its primary data ^ource[Ji]. 


Question: We sometimes have flights which are delayed for several 
hours which, for various reasons, require the DCS STD and STA to 
be changed to reflect the new departure and arrival times. The 
updated times will be reflected in the flight departure message. Is 
this allowed? 


Answer: The STD and STA reported by the carrier Primary CRS are required to be 
reported in all pre-departure and departure messages[J2], 

In exceptional circumstances, such as during Irregular Operations, it is accepted that the 
times used within the carrier and DCS systems must be updated and will not reflect the 
originally reported CRS STD/STA times. In such circumstances the following options 
should be employed in order of preference. 

a. Pre-departure messages should not be transmitted until the expected SDT and STA 
are known and should then be used consistently up and including in the departure 
message. 

b. Where an essential change in carrier/DCS system STD time, after the transmission 
of any previous messages in relation to the flight, will result in change of STD in any 
subsequent messages and/or the departure message, previously submitted traveller 
records must be retransmitted reflecting the amended timings to ensure consistency. 

Note: A change in STA alone does not require previous messages to be submitted; only 
when changed in conjunction with a change in STD. 


Question: We have travellers who arrive at the airport with non¬ 
standard travel documents, embassy or consulate letters after losing 
their travel documents; what details are required to be reported? 


Answer: Where travellers have lost their travel document they should be in possession 
of a letter from the embassy or consulate. This letter, if it does not have a serial number, 
will have a file reference. The letter serial number or file reference should be entered as 
the travel document number. The GHA/Carrier should enter the traveller's name, gender 
and DOB as given in the letter, if any details are missing from the letter they should be 
obtained from the traveller. The letter should be used to obtain the date of expiry. The 
embassy or consulate that issued the letter should be entered as both the traveller 
nationality and the Issuing State for the travel document. 

If the letter does not have an expiry date, since it is a single-use "get you home" 
document, the date of use should be entered. If it has a validity period, enter the last 
date of the validity period. If the document does not have a serial number then the file 
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2.4 

2.4.1 


2.5 

2.5.1 


reference should be entered, removing any symbols and concatenating the resulting 
alphanumeric string, e.g. FO/231/97 12 June 2009 would become F02319712062009. If 
the length of the string is too long for the system then it should be truncated by omitting 
the final characters. 

The document should be entered as type “F” - other valid travel document. 


Aircraft Leasing 

Question: Sometimes we operate flights where we either dry lease or 
wet lease the aircraft; we also have occasions where we “damp” 
lease the aircraft - providing our own cabin crew. In such 
circumstances, who is responsible for providing the required 
passenger and crew pre and post departure messages? 

Answer: The Lessor as owner or agent of the aircraft is responsible for providing the 
data in all circumstances with the sole exception of that of a dry lease, where the Lessee 
becomes responsible for providing the data as the agent of the aircraft. 

This does not mean that the Lessor must submit the data themselves; there will be 
circumstances where crew and passenger data could be submitted by different 
companies for IT, legislative or other reasons. However, the Lessor retains responsibility 
for ensuring that the data is submitted. 


1) The term ‘Lessor’ defines the person or organisation who assigns the lease to 
another party. In all cases, except that of dry lease, this should be the company who 
provide the AOC, or other country equivalent, for the aircraft. 

2) The term ‘Lessee’ defines the party to whom a lease is given or takes on the lease of 
the aircraft. In the case of a dry lease, this should be the company who then provides 
the ‘AOC’, or other country equivalent, for the aircraft. 

3) The flight number or Carrier code assigned to a flight is not the defining factor as this 
may be provided by the lessee; the lessor retains responsibility in all cases except 
for that of dry lease. 

4) Aircraft Lease Definitions: 

• Wet Lease: The Lessor provides the aircraft, crew, maintenance and insurance 
and typically charges the lessee on the basis of block hours. 

• Damp Lease: A Damp Lease is similar to a Wet Lease, but the Lessor provides the 
aircraft without cabin crew, who are provided by the Lessee. 

• Dry Lease: The Lessor provides the basic aircraft without crew, maintenance or 
insurance. Dry lease normally requires the Lessee to put the aircraft on his own 
AOC and provide aircraft registration. 

Reporting Metrics 

Question: We wish to ensure we do not fall below the standards 
required in accuracy and timeliness for the submission of data. Can 
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you provide us with the metrics and/or percentages used as 
thresholds and how these can be monitored? 


Answer: Carriers must provide TDI that is: 

• Timely: i.e. for each service, data will be provided within the agreed timescales. 

• Complete: i.e. data will include all mandatory data fields for all passengers and crew 
travelling on each service, together with complete service information. 

• Accurate: Carriers must take all reasonable steps to ensure that passenger and crew 
data is identical to that provided in the travel document. 

The e-Borders system will generate regular data quality reports that will be used to 
monitor data quality. Carriers will be advised of problems with submitted messages and 
supported in resolving any issues that arise. 


Question: We are concerned that some of our message submissions 
may be marked as having been submitted late because of 
inaccuracies in the flight monitoring systems used as reference data 
such as flight cancellations and delays. How do we ensure we will 
not be penalised if such errors occur? 


Answer: Concerns over the accuracy of flight reference data have been noted. If quality 
issues identified during live service are found to be the result of inaccurate reference 
data, appropriate action will be taken to address the issue and we will work with Carriers 
to achieve a resolution. 


The Common Travel Area & Domestic Travel 

Question: Which states form the CTA and what discussions has the 
UK Government had with other CTA governments about the 
operation of the CTA? 

Answer: The Common Travel Area is formed of the United Kingdom, the Republic of 
Ireland and the Crown Dependencies (consisting of the Isle of Man and the Channel 
Islands). The UK Government, in partnership with the Governments of the Republic of 
Ireland and the Crown Dependencies, has developed a number of proposals for 
modifying the operation of the CTA. 


Question: What changes are proposed on air and sea routes 
between the Crown Dependencies and the UK? 


Answer: For operations on routes between the Crown Dependencies and the UK we do 
not intend to introduce a document requirement or collect e-Borders data. We will 
instead treat the Crown Dependencies as being inside the ‘e-Borders security ring’. 
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Question: What changes are proposed on air and sea routes 
between the Republic of Ireland (ROI) and the UK? When will these 
begin to take place and what information will be required? 

Answer: For air and sea routes between the UK and Republic of Ireland (ROI) the 
intention was to use the Borders, Citizenship and Immigration (BCI) Bill to provide us 
with an unequivocal legal basis for our plans to introduce intelligence led checks on intra- 
CTA journeys. 

The CTA clause was withdrawn from the BCI Bill before it became an Act to prevent any 
delay to the passage of the Bill through Parliament 


The CTA proposals are crucial if we are to make the border between the UK and the 
Republic of Ireland stronger than ever, we still intend to pursue these changes, and we 
will be looking to bring these proposals back to Parliament at the first possible 
opportunity. 


With the legislation in place, the intention is to introduce e-Borders on routes between 
the Republic of Ireland and the UK along with a requirement for persons travelling on 
these routes to carry their passport or national identity card. Subject to the legislation, it 
is anticipated that data collection on these routes will commence in late 2010. It is 
expected that the required data will be all TDI elements found in the MRZ on an ICAO 
format Machine Readable Travel Document. In the short term, there will be no 
substantial changes to operations at the primary line and rolling out e-Borders to ROI will 
support an intelligence led approach to enforcement. 


Question: We understand that there will be a future requirement to 
provide information on domestic travel (DTI) within the UK. What 
information will be required to be reported to e-Borders and in what 
timeframe? 

Answer: Section 14 of the Police and Justice Act 2006 introduced a new power to 
allow the police to collect travel information on internal UK domestic flights and voyages. 
The intention is to focus this power on air and sea routes between Northern Ireland and 
Great Britain. This is a police power chiefly for counter terrorism purposes. Should the 
Government decide to proceed, there will be a 12 week Regulatory Impact Assessment 
where all interested parties will have the opportunity to comment on the proposals. 


Maritime Issues 

Question: We operate cruise ships which may dock to allow 
passengers to disembark for shore excursions at several locations 
after the first arrival at a UK port. Are we required to provide check¬ 
in and Departure messages for each stop/departure? 


Answer: If a ship plans to visit the UK, pre and post-departure messages must be sent 
listing all crew and passengers on board regardless of any intent to disembark. If the 
ship intends to visit more than one UK port before departing for another foreign port, then 
the port of arrival and the subsequent port must both be identified in the submitted 
messages. In the case of further subsequent multiple stops in the UK no message is 
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required until the vessel sets sail for a foreign port. Pre and post-departure messages 
must then be sent prior to the ship departing the UK for a foreign port, stating the UK port 
of departure and the first foreign port of arrival. 


Question: What about freighters that are unloading/refuelling before 
going to another domestic port or another international port but 
where no crew or passengers are either embarking or 
disembarking? 


Answer: If a ship plans to visit the UK, pre and post-departure messages must be sent, 
listing all crew and passengers on board the vessel regardless of their intention to 
remain on board during the period of the visit. The message must be sent in respect of 
the first port of call in the UK for an arriving vessel and the last UK port of call for a 
vessel setting sail for a foreign destination. 


Question: We often sail for the UK or Europe without knowing our 
destination port, e.g., tankers may leave the Gulf with a destination 
of LEFO (Lands End For Orders), when a destination will be provided 
once the purchaser of the cargo is known. Hence, we do not know 
the port, date of arrival, or time of arrival upon departure. How do we 
report the journey? 

Answer: If the journey destination at the time of departure is not known to be the UK, no 
reporting is required. Once the intention to land at a UK destination is known pre and 
post-departure messages must be submitted. The submitted SI data should include the 
last port of call before arrival in the UK together with the actual date and time of 
departure. 


Data Protection 

Question: We are required to comply with the data protection laws 
of the states from which we operate. What assurance can you 
provide us that we will not be infringing these laws by providing the 
data you request? 

Answer: The e-Borders programme is engaged with the UK Information Commissioners 
Office. The Information Commissioner has visited the NBTC[J3] and is satisfied the e- 
Borders system is compliant from both a UK (Data Protection Act 1998) and overseas 
law perspective. 

There is awareness of specific industry concerns concerning the collection, storage and 
transmission of such data in other states. These and any other concerns will be dealt 
with on a case by case basis. If any carrier encounters a specific problem with officials 
in any country, the issue should be raised with the UKBA and then dealt with on a 
country to country basis facilitated by the UK Border & Visa Policy authorities. 

There is a Code of Practice on the management of information shared by the border 
agencies and a commitment to continue to review with the Information Commissioners 
Office. A copy of the Policy is available at: 
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http://www.ukba.homeoffice.qov.uk/sitecontent/documents/manaqinqourborders/eborders/codeofpr 

actice/ 


Question: Can you confirm that the e-Borders system is accredited 
for the receipt of personal data? 

Answer: The e-Borders system is subject to the HMG Manual of Protective Security 
and is accredited by the Home Office Department Security Unit (DSU). CESG is 
represented on the e-Borders Security Review Group and is involved in the accreditation 
process. 


e-Borders Alerts to UK Border Agencies on 
Passengers/Crew 

Question: If we submit the details for a passenger, will we receive 
notification of whether they are cleared to travel or not? 


Answer: The e-Borders system is not an interactive system and does not provide either 
an authority to carry or denial of authority to carry response. 


Question: How much information will we be provided when an alert 
is provided about a passenger? Will we be advised if a passenger 
has to be apprehended as a result of a warning? 


Answer: Alerts issued will be to the appropriate UK border agency who will potentially 
intervene on a passenger on arrival in the UK or to prevent a passengers/crew departure 
from the UK. The UK border agencies will work in partnership with the Carrier’s handlers 
locally to effect the intervention. 


Question: How will the UK's proposed Authority to Carry (ATC) 
scheme operate on services inbound to the UK? 

Answer: The funding, operation and messaging arrangements for an ATC scheme have 
not been confirmed and there is no planned commencement date. In the event that such 
a scheme is introduced, we have agreed that ATC proposals will be preceded by a trial 
involving the carrier industry and will take due account of the solutions already in place 
and the developments and standards adopted by other countries for similar schemes. 

BUSINESS PROCESS QUESTIONS 
Crew Questions 
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Question: Who are considered as part of the crew of a service? We 
carry additional staff on some trips such as animal handlers, 
medical staff, etc. Are they considered as part of the crew? 

Answer: In this context, crew are the staff assigned to operate the service, including 
flight deck and cabin crew members as well as Air Marshalls or other security personnel. 
All travellers on the service must be reported as either passengers or crew. If the 
service is being operated as a passenger service, staff members in excess of the 
operating crew should be reported as passengers. If the service is being operated as a 
non-passenger service, all staff should be reported as crew. 


Question: The crew operating our service into the UK will also be 
operating the return service and will not leave the vicinity of the 
vehicle to clear immigration. Do we still need to report them in 
check-in/Report-in and Departure messages? 


Answer: Yes. All travellers, crew or passengers, who are arriving or are expecting to 
arrive in the UK, or are leaving or expecting to leave the UK, must be reported, 
regardless of their intentions. 


Departure Messages 

Question: If a passenger has checked in for one flight, and then 
subsequently moves to another flight for operational reasons 
(mechanical, weather, etc.), must the check-in data for that 
passenger be submitted again, or can the passenger simply be 
added to the departure message for the new flight? 

Answer: Data previously submitted for the original flight cannot be associated with the 
new flight; the data has to be resubmitted. Check-in data and departure confirmation 
must be submitted for the flight the passenger actually travels on. 

a) Passengers that are checked-in for a flight and, for whatever reason, do not depart 
on that flight, must either be reported in a departure exception message or omitted 
from a departure confirmation message for the missed flight. 

b) If passengers are transferred to a different flight, for whatever reason, both check-in 
(pre-departure) and departure messages must be submitted for the new flight. 

c) Carriers do not need to take any reporting action in the case of the delayed or 
cancelled service. 


Question: We operate services using leased aircraft where the flight 
deck crew are supplied by the lessor company whilst we provide the 
cabin crew. Is it acceptable for the crew to be reported 
independently by each company for the flight using their own 
systems? 
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3.3 

3.3.1 


3.3.2 


3.4 

3.4.1 


Answer: Pre-departure (crew report-in) messages may be submitted by both companies 
as e-Borders is able to accept multiple Report-in messages from multiple sources as 
long as the SI data is consistent across all messages. 

However, e-Borders requires a single departure message covering all crew members. 
Whilst the legal responsibility for submission of the data lies with the lessor company, the 
decision as to which company actually submits the combined data is a decision for the 
companies involved. 


Transit and Through-Checked Passengers 

Question: We have international services that transit through the 
UK, and maintain the same flight number on both the inbound and 
outbound flight segments. For through-checked passengers on 
these flights, are we required to send separate check-in and 
departure messages for the outbound segment? 

Answer: Yes. Passengers (and crew) arriving or expected to arrive in the UK or 
departing or expecting to depart the UK must be reported irrespective of circumstances. 
Check-in, (report-in) and departure messages must be sent for all passengers and crew 
on both the inbound and outbound voyages of such services. 

Question: We have international services both into and out of the 
UK. We have transit passengers who change flights without clearing 
immigration. Do we have to report them in the check-in and 
departure messages for the outbound flight? 

Answer: Yes. Passengers (and crew) arriving or expected to arrive in the UK or 
departing or expecting to depart the UK must be reported irrespective of circumstances. 
Check-in and departure messages must be sent for all passengers and crew on both the 
inbound and outbound voyages of such services. 


Short Notice & Charter Operations 

Question: We add new routes at short notice and also provide short 
notice ad-hoc charter flights. What provision is there for certifying a 
new DCS at short notice? What do we do if the departure airport 
does not have a DCS system? 

Answer: 

a) The current procedures for certifying a new DCS system have been designed to be 
as streamlined and fast as possible and, consequently, “fast track” certification is not 
applicable. To the extent possible, Carriers should advise their DCS suppliers to 
certify the DCS systems at all anticipated operating locations. 

b) For ad-hoc / unplanned (one-off charter) flights, Carriers are expected to provide the 
data through existing mechanisms. Where no capability exists, Carriers are expected 
to default to alternative arrangements - e.g. the Excel file format. Where data cannot 
be provided the carrier is expected to inform the e-Borders Service Desk who will 
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provide advice and guidance. Details of the Service Help Desk can be found in the e- 
Borders Live Service documentation. 


Multi-Leg Journeys 

Question: What are the business rules for the reporting of multi-leg 
flights to e-Borders? 


Answer: Multi-leg flights should be reported in accordance with the following rules and 
guidance. 

The following definitions are used throughout this response. 

• Flight Leg (or “flight sector”): The non-stop operation of an aircraft between 
two consecutive airports. 

• Flight: A series of one or more flight legs flown consecutively using the same 
flight number. E.g. YY945 is a four-leg flight, ACE-PMI-MAN-EDI-OSL. 

• Route: A series of consecutive airports served by a flight. E.g. Carrier YY 
operates 2 flights per day on the four-stop route ACE-PMI-MAN-EDI-OSL. 

• Voyage: A movement of an aircraft between two, not necessarily consecutive. 
airports along a route. 

Figure 6 depicts a multi-leg flight along the route A-B-C inbound to the UK. Under UK 
legislation, pre-departure data and departure confirmation must be submitted to e- 
Borders for all passengers and crew that will travel across the UK border. In this 
example, that’s everyone on board flight leg B-C. 

To allow for variations in the programming of different DCS equipment, Carriers have two 
options for submitting this data: 

Option 1: Carriers may submit data for all passengers and crew for the voyage from the 
last airport before the border to the first airport after the border. In this example, all 
passengers and crew can be reported for the voyage B-C. 

Option 2: Carriers may submit the data for each voyage where passengers and crew 
board the flight intending to cross the border. In this example, passengers and crew that 
board at airport A can be reported on voyage A-C, and passengers and crew that board 
at airport B can be reported on voyage B-C. 
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Figure 6 - Multiple Voyages on a Multi-Leg Flight 


Service Information (SI) Identifies the Voyage 

When submitting data to e-Borders, Carriers identify the voyage on which the 
passengers and crew are travelling by reporting its Service Information (SI) data. 
Different voyages reported for the same multi-leg flight are distinguished in this manner. 
Carriers submit nine elements of SI data, as listed below. Items 1-6 are used by e- 
Borders to establish voyage uniqueness. These six must remain the same in each pre¬ 
departure and departure submission for that voyage. 

1. Carrier Code 

2. Voyage ID (flight number) 

3. Last Place/Port of Call (origin of the reported voyage) 

4. Scheduled Departure Date 

5. Scheduled Departure Time 

6. Place/Port of Initial Arrival (destination of the reported voyage) 

7. Scheduled Arrival Date 

8. Scheduled Arrival Time 

9. Subsequent Place /Port of Call within the country of destination 


Inbound Flight Examples 

The following example demonstrates the inbound reporting options for travellers 
boarding a multi-leg flight inbound to the UK. 


UK Border 



Figure 7 - Multiple Leg Inbound Flight 

Carriers may utilise either of two options as illustrated in figure 7. 

Option 1 - Report all passengers and crew on the voyage from DBX to LHR. 

Option 2 - Report passengers and crew on voyages from their boarding airport to their 
destination airport in the UK. 

There are five cases to consider: 

(a) Travellers embarking at SYD and disembarking at DBX. These travellers are not 
reported as they will not enter the UK. 
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(b) Travellers embarking at SYD and disembarking LHR. These travellers will enter 
the UK and are reported as travelling on SYD-LHR with a subsequent airport of 
EDI. 

(c) Travellers embarking at SYD and disembarking EDI. These travellers will enter 
the UK and are reported as travelling on SYD-EDI. 

(d) Travellers embarking at DBX and disembarking LHR. These travellers will enter 
the UK and are reported as travelling on DBX-LHR with a subsequent airport of 
EDI. 

(e) Travellers embarking at DBX and disembarking EDI. These travellers will enter 
the UK and are reported as travelling on DBX-EDI. 


3.5.1.3 Reporting of Travellers Transiting Through the UK 

UK legislation requires data to be submitted for all travellers both entering and leaving 
the UK, regardless of whether they leave the aircraft. For travellers transiting through 
the UK, whether on continuing multi-sector flights or on separate in-bound and out-bound 
flights, separate data submissions must be made for their inbound and outbound travel. 

The following examples illustrate the various reporting options for transit passengers and 
crew on the multi-leg flight shown in figure 8, which retains a single flight number while 
transiting through the UK. 
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Figure 8 - Multiple Leg Flight Transiting the UK 


3.5.1.3.1 Transit Flight Inbound Reporting 

Travellers embarking at DBX and disembarking at JFK or LAX will cross the UK border 
inbound and must be reported inbound. As shown in figure 9, these travellers may be 
reported as travelling on voyage DBX-LHR with a subsequent airport of EDI or 
alternatively, as travelling on voyage DBX-EDI. 
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Figure 9 -Transit Flight - Inbound Voyage Reporting 


3.5.1.3.2 Transit Flight Outbound Reporting 

Case 1: Travellers embarking at DBX and disembarking at JFK. These travellers will 
cross the UK border outbound and must be reported outbound. As shown in figure 10, 
they may be reported in either of two ways. 

a. Travelling on voyage LHR-JFK, with subsequent port of LAX (optional) 

b. Travelling on voyage EDI-JFK, with subsequent port of LAX (optional) 
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Figure 10 - Transit Flight - Outbound Voyage Reporting (Case 1) 


Case 2: Travellers embarking at DBX and disembarking at LAX. These travellers will 
cross the UK border outbound and must be reported outbound. They may either be 
reported as travelling to airport JFK as described above (figure 10), or in either of two 
additional ways, as shown in figure 11. 

a. Travelling on voyage LHR-LAX. 

b. Travelling on voyage EDI-LAX. 



Figure 11 - Transit Flight - Outbound Voyage Reporting (Case 2) 
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Question: We have a service operating Rome-Paris-London. Some 
passengers and/or crew board at Rome for London, some board in 
Rome and disembark at Paris, and some join at Paris for London. 
The service retains the same flight ID. What messages do we send? 


Answer: Check-in and departure messages must be submitted for all passengers and 
crew travelling to the UK. e-Borders supports the reporting of the above itinerary in two 
ways, to support the business processes in various air, maritime and rail industries. 


a) Check-in and Departure messages for all passengers and crew travelling to London 
may be sent just for the last leg of the service, Paris-London. 



b) Check-in and departure messages may be submitted independently for the voyages 
Rome-London and Paris-London. Rome would only submit data for passengers and 
crew travelling through to London; Paris would only report passengers and crew 
joining in Paris. 



Question: If a passenger is checked-through to travel Rome-Paris- 
London, but then unexpectedly disembarks at Paris, for illness or 
another reason, what messages do we send? 


Answer: No messages are required to be sent. 


Question: We operate flights from the Far East to the UK which may 
be required to divert for a refuelling stop before continuing to the 
UK, e.g. SYD-LHR stopping at CDG. No passengers or crew 
disembark during the stop and none board. What reporting actions 
are we required to take after the initial check-in and departure 
messages from SYD? 

Answer: If no changes are made to the crew and no opportunities occur for new 
passengers to embark, no messages need to be sent. If any additions to crew or 
passengers are made, pre-departure messages must be sent listing any joining crew or 
passengers and a departure message must be sent after push-back. 
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Question: We code share with another airline on flights into and out 
of the UK. Each of us operate inbound and some outbound flights 
under our own flight numbers. Regardless of which Carrier operates 
the flight, passengers are booked through on a single flight number 
which appears on their tickets for both inbound and outbound flight 
legs. Both Carriers’ flight numbers are displayed on the airport 
check-in and departure boards. Which Carrier is responsible for 
submitting pre and post-departure messages for each flight leg? 


Answer: The Carrier operating the service for the leg into and/or out of the UK is legally 
responsible for ensuring all passengers and crew are reported. Regardless of who 
actually transmits the messages, the Carrier code and flight ID of the Carrier operating 
the service must be submitted. 


Question: We fly a multi-leg flight outbound from the UK to Australia 
(LHR-DBX-SYD) with passengers planned to disembark at each 
destination. How do we report this flight? 


Answer: Pre-departure (check-in) and departure messages must be submitted for all 
passengers and crew travelling from London. e-Borders supports the reporting of the 
above itinerary in two ways. 

a) Pre-departure and departure messages for all passengers and crew travelling from 
London may be sent just for the first leg of the service, London-Dubai. 


All Pax & Crew ex-London 


(°r~ 



London 

DiXkU 

Syitiey 


b) Pre-departure and departure messages may be submitted independently for the 
voyages London-Dubai and London-Sydney. 
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3.5.8 


3.5.9 


3.6 

3.6.1 


Question: We operate a service which transits through the UK en- 
route to another international destination. For example we fly AMM- 
LHR-JFK. The flight retains the same flight ID. How do we report the 
flight, since the flight ID remains the same for both voyages on the 
same day? 

Answer: The inbound and outbound flight legs must be reported as separate inbound 
and outbound voyages, each with pre-departure and departure submissions for all crew 
and passengers. The same flight ID may be used for the voyages into and out of LHR. 
e-Borders will differentiate these two voyages by their differing departure and arrival 
airports and times. 

Question: We code share on a multi-leg flight which transits through 
the UK. We sell tickets using our code for passengers booked 
through the UK, disembarking in the UK and departing the UK. The 
other Carrier does the same. We operate the service into the UK; the 
other Carrier operates the service out of the UK using their flight 
route ID. How do we report the flight? 

Answer: The Carrier operating the flight leg that crosses the border is responsible for 
ensuring all required messages are submitted. The Carrier providing the service into the 
UK is responsible for reporting all passengers and crew on board the inbound aircraft. 
The Carrier operating the service out of the UK is responsible for reporting all 
passengers and crew on board the outbound aircraft. 

Question: e-Borders only requires that the departure port, arrival 
port, and subsequent port in the country of destination be reported 
in the SI of a message. This is only a subset of the ports of call 
allowed by the UN/EDIFACT PAXLST standard and IATA Guidelines. 
Our standard message, used to support other systems, supports the 
reporting of other locations, such as passenger itineraries and 
additional ports outside the UK, using the LOC segment together 
with element 3227 codes such as 22,174,179 etc. Do these need to 
be removed from the message we send to e-Borders? 

Answer: No. As long as Carriers provide the required segments in accordance with the 
e-Borders PAXLST ICD (reference B), additional segments which conform to the 
PAXLST standard and IATA guidelines may be included in the message. e-Borders will 
correctly parse the message and extract the requested segments and elements. 


Diversions, Delays & Cancellations 

Question: What happens if a voyage is cancelled after all the 
passengers have been checked-in, having cleared security, and we 
then transfer them to another flight? Can we include them on just 
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the post-departure message for the voyage on which they actually 
departed? 


Answer: In the instance where a flight is cancelled and passengers are transferred to a 
different vessel, separate check-in and departure messages for the passengers must be 
submitted for those passengers with the new voyage’s SI data. 


Question: Can a voyage keep using the originally submitted SI data 
if the scheduled time of departure is delayed into the next day? 


Answer: The intent of requiring SI data to be unique for a day is to ensure that there can 
be no confusion concerning which flight a traveller actually takes. If the voyage will be 
completed prior to the departure of the next service using the same route ID, the original 
SI should be maintained. If any overlap between the two services may occur, then an 
alternate flight ID should be used for one or both of the services. If a flight ID is changed, 
previously submitted pre-departure (check-in) messages for the amended service must 
be resubmitted using the new SI. 


Question: What action is required when a UK outbound voyage, e.g. 
ABZ-CFU, diverts to another UK airfield to correct a problem, such 
as a faulty cargo door light, then proceeds after a short delay? 


Answer: If no changes are made to the crew and no opportunities occur for new 
passengers to embark, no messages need to be sent. If any additions to crew or 
passengers are made, check-in and/or report-in messages must be sent listing any 
joining crew or passengers and a departure confirmation must sent from the diversion 
airport when that voyage departs. 


Question: What reporting action is required if a voyage is cancelled? 

Answer: No messages are required, as notification will be received through other 
sources. 


Question: What reporting action is required if an inbound voyage to 
the UK diverts to an alternate UK airport or an alternate international 
airport? 

Answer: No additional messages are required, as notification will be received through 
other sources. 


Question: What reporting action is required if an international 
overflight, not planned to land in the UK, diverts to a UK airport? 


Answer: No messages are required, as notification will be received through other 
sources. It is understood that for such unplanned circumstances, the departure details 
may no longer be available for retransmission. 
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3.6.7 Question: What reporting action is required if an aircraft returns to 


the gate after the departure message has been sent because a 
passenger needs to be removed from the aircraft? Do we need to 
send a second departure message or resubmit all messages with an 
amended departure time? 

Answer: No messages are required, as notification will be received through other 
sources. The sending of the first departure message meets the required reporting 
obligation. 
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3.7 

3.7.1 


3.7.2 


3.8 

3.8.1 


System Outages 

Question: What action should be taken if there is system failure, 
either in our CRS, the DCS, a third party or at e-Borders? Do we 
have to delay departure until check-in and departure messages have 
been sent? 

Answer: If a Carrier’s system or a connection between their system and the e-Borders 
system fails or is unavailable for any reason, the Carrier is expected to inform the e- 
Borders Service Desk who will provide advice and guidance. The flight does not have to 
be delayed but may receive closer scrutiny upon arrival for a UK inbound flight. 

Question: What are the requirements for submitting check-in and 
departure messages after recovering from a system outage, if 
voyages have either departed or have even departed and arrived at 
their destinations? 

Answer: Where information is still available and able to be submitted, it should be 
submitted. 


Connectivity 

Question: Can we submit our data through 3rd parties or do we need 
to use the Internet? 

Answer: Connectivity to e-Borders is via the Internet. Carriers may instead choose to 
send data to e-Borders via their existing connections to ARINC or SITA. ARINC and 
SITA will then transmit that data to e-Borders. Other third parties, such as local DCS, 
may also connect to e-Borders on behalf of client Carriers. Any third party that submits 
data to e-Borders must go through the e-Borders registration and certification processes, 
however, Carriers are responsible for all data submissions. 

Question: We operate services to airports without any e-Borders- 
compatible DCS systems and wish to send messages directly to e- 
Borders using either local ISP providers or means such as mobile 
wireless services. This means our computers will be using dynamic 
IP addresses provided by the service provider. Is this OK? 

Answer: No. For security purposes, static registered IP addresses are required for 
connection to the e-Borders system. e-Borders’ external firewall will reject any 
connection from a non-registered address. 

Carriers that are unable to use static IP addresses are recommended to either send their 
data to a registered Carrier system which can then relay the data to e-Borders or to seek 
a registered third party to act as a gateway. 
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TECHNICAL QUESTIONS 

Question: What types of travel documents are acceptable to the e- 
Borders system? 


Answer: e-Borders supports a UK specific document list as detailed below. Additionally, 
Carriers may use other document types/codes as detailed in References 1 to 4 of the e- 
Borders PAXLST ICD (Reference B). 

P: Passport 

G: Group Passport 

A: National Identity Card or Resident Card 

C: National Identity Card or Resident Card 

I: National Identity Card or Resident Card 

M: Military Identification 

D: Diplomatic Identification 

AC: Crew Member Certificate 

IP: Passport Card 

F: Other approved non-standard identity documents used for 

travel 

States may approve other documents as identification for travel use and may assign 
other document codes not included or conflicting with the above, in such circumstances 
they should be reported using the code ‘F’. 

Question: Our systems read the document code as given in the MRZ 
of a travel document and does not allow the operator to change the 
code. We are aware of codes which are not included in the e- 
Borders or supported lists. What do we do? 

Answer: In such circumstances it is permissible to transmit the code assigned in the 
MRZ of the document. 


Question: Some elements of the e-Borders PAXLST message are 
stated as being mandatory, but are shown as being conditional or 
N/A in the UN/EDIFACT PAXLST standard or WCO/IATA 
Implementation Guide. Which is correct? 


Answer: Some fields, that are identified as Conditional or N/A in the UN/EDIFACT 
PAXLST standard or WCO/IATA PAXLST Implementation Guide, are, due to their 
purpose and use, required by e-Borders and are therefore mandatory within the e- 
Borders PAXLST message format. Where any discrepancy occurs, the e-Borders 
PAXLST ICD, reference B, should be followed. 
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4.1.5 


4.1.6 


4.1.7 


Question: We operate a ferry service that carries buses/coaches as 
well as freight vehicles. The e-NOA/D ICD (reference C) says that the 
vehicle registration mark (VRM) must be reported for both 
passengers and crew. What is the status of the vehicles’ crew (such 
as drivers)? Are they required to be reported, and if so, how? 

Answer: In this context, crew is defined solely as the employees of the Carrier assigned 
to operate the ferry service. All occupants of vehicles, including their drivers, are to be 
reported as passengers. 

Question: What is the departure time to be included in the pre¬ 
departure message and the post-departure message? Is it the 
published time or the time as amended for delays such as weather 
etc? 

Answer: The departure time to be reported in the SI portion of the messages is the 
planned/scheduled time at which the Carrier normally expects the service to depart. 
Usually this will be the Carrier’s published scheduled departure time. Once a time has 
been used within an initial check-in or report-in message for the voyage the same time 
must be used for all subsequent messages submitted for the same voyage. Any 
messages sent with a different time will be regarded as a different voyage. 


Question: What character sets does e-Borders accept? 

Answer: The e-Borders system accepts messages coded using UTF-8 which supports 
multiple character sets including Latin letters with diacritics and characters from the 
Greek, Cyrillic, Coptic, Armenian, Hebrew, Arabic, Syriac and Tana alphabets. 

Where messages are sent in a standardised message format, such as PAXLST or e- 
NOAD, the content should adhere to the standard if more prescriptive. 

Question: What do we enter as the sender ID in the PAXLST UNB 
and UNG segments ? 

Answer: UNB element 0004 should be populated with the ID of the agency transmitting 
the message, which can be a carrier, DCS, GDS or other 3 rd party. Preference should be 
given to using an assigned IATA, ICAO or e-Borders code, if none is allocated the 
normal agency name or identifier should be entered. 

UNG element 0040 should be populated with the ID of the Carrier responsible for the 
data, which is not necessarily the same as the code used to populate the carrier Route 
ID and code in the TDT segment. 

Identification of who is responsible for the submission of data is covered in section 2 - 
Aircraft Leasing. 
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Question: Does the travel document number need to be different 
between an infant passenger and an accompanying adult? What 
about group and family passports? 


Answer: Some states require individual travel documents for all travellers, regardless of 
age; others permit infants to travel on their parent’s or guardian’s travel documents. Still 
others, such as the UK, support group passports for children on activities such as school 
trips. Accordingly, e-Borders supports individual travel documents, family passports and 
group passports. Family passports should be reported as document type “P” and group 
passports as document type “G”. When group and family passports are used, multiple 
travellers will share the same travel document number. When that occurs, that same 
number should be submitted for each affected traveller. 


Question: We carry student parties travelling on Group passports 
who therefore have the same Travel Document Number (TDN). Are 
we still allowed to just submit the TDN and issuing state in a 
departure message, even if all those originally checked-in did not 
depart? 

Answer: Yes, the possibility of a discrepancy between the number who were checked-in 
and those who departed is recognised and accepted in such circumstances. If the 
Carrier wishes to avoid ambiguity then full TDI should be submitted for individuals 
travelling on the same travel document in the post-departure message. 


Question: We provide unique identifiers for all passengers when we 
submit a US CBP PAXLST message using multiple RFF segments. 
Can we use these in e-Borders check-in messages, to provide 
updates to passenger details when they arrive at the airport and in 
the post-departure message? 


Answer: The e-Borders system is designed to support data submittals across a range of 
industries (air, maritime and rail), using message formats where unique identifiers are 
not universally supported. Therefore, the e-Borders system does not follow the US CBP 
practice of using multiple RFF segments to assign unique passenger identifiers. 

While multiple RFF segments may be included in the message, they will not be used by 
e-Borders. e-Borders only utilises an RFF:AVF segment to submit an OPI Locator Code. 

TDI must be provided in subsequent messages as detailed in the e-Borders 
documentation. Carriers may submit unique identifiers if they see fit but these must 
always be accompanied by the mandatory TDI data elements specified in the e-Borders 
interface documentation. 


Question: We carry passengers who present group travel 
documents other than passports, such as NATO Travel Orders. What 
travel document type should we use? 


Answer: Where a travel document is presented as the sole travel document for more 
than one traveller, then the travel document should be reported as Group - document 
code “G”, 
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Where the document type is presented together with a second form of identification, 
such as a personal military ID card for each traveller, and where the system permits, the 
details of both documents should be entered. 


Batch and Multi-Part Messages 

Question: We use the UN/EDIFACT PAXLST interface. Can we send 
messages within UNG/UNE groups and UNB/UNZ interchanges? 


Answer: e-Borders supports the use of both UNG/UNE and UNB/UNZ segment groups. 
A single instance of a PAXLST message may be included within a UNG/UNE group and 
a single instance of a group within a UNB/UNZ interchange is allowed. 


Question: We submit PAXLST post-departure messages using the 
SITA/ARINC networks and split the messages into 3.5/4K blocks 
prior to transmission. Is this acceptable? 


Answer: Post-departure messages PAXLST messages split into blocks are accepted by 
the e-Borders system provided that: 

a) All message parts are well formed, with each part containing all required SI data 
and individual traveller records are not split between parts. 

b) Each part is correctly annotated and numbered using the PAXLST UNH 
composite element SOI 0 - Status of Transfer, as described in the e-Borders 
PAXLST ICD. 

Miscellaneous 

Question: If a passenger or crew member has two travel documents, 
can we send details from both? 


Answer: Yes. Both documents will be processed by e-Borders. If a passenger or crew 
member is reported with two travel documents, both must be included in both the pre 
and post-departure messages. 

Question: Can a passenger or crew member depart for the UK on 
one valid travel document and arrive in the UK on another valid 
travel document? 


Answer: Yes. 


Question: We carry passengers where the travel document is a 
removal order or similar document without a document expiry date. 
What date do we report when reporting the document data? 
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Answer: Where the presented document is a one-use document only valid for that flight, 
the date of departure should be entered as the expiry date. 


Question: We receive traveller country data, both for nationality and 
country of issue, in formats utilising both 2 character and 3 
character codes. The e-Borders ICD states these must be entered 
using those specified in the ICAO 9303 part 1 document. Do we 
have to transliterate the country codes we receive to those listed in 
the 9303? 


Answer: No, transliteration is needed. e-Borders supports the ISO 3166-1 alpha-2 and 
alpha-3 country code lists together with the extensions as specified in ICAO 9303 part 1 
to cover international organisations such as the U.N. and Red Cross. 


Question: The e-Borders PAXLST ICD example shows the route 
identifier in the TDT segment, element 8028, as including the IATA 2- 
alpha Carrier code. However, all the examples in the provided 
Technical Data Pack contain only the numerical characters. Do we 
include the Carrier code or not? 


Answer: The Carrier code is not mandatory with element 8028, but is supported; it is 
mandatory within element 3127. When a carrier code is included as part of the route ID 
in 8028 it must match the code used 3127. e-Borders supports both 2-alpha IATA codes 
and 3-alpha ICAO codes as part of the Route Identifier. Where the Carrier does not have 
an assigned IATA or ICAO code and must enter their e-Borders assigned code, this must 
only be used in element 3127. The following are examples of valid TDT 8028 and 3127 
combinations. 

a) TDT+20+BA231+++BA’ 

b) TDT+20+BAW231+++BAW’ 

c) TDT+20+231+++BA’ 

d) TDT+20+231+++BAW’ 

e) TDT+20+231+++EB4567’ 


Question: We have passengers who arrive for their journey with a 
travel document which is past its expiry date and who we agree to 
carry. The problem is that the DCS system will not accept an elapsed 
date, only the current or a future date. What date do we report when 
reporting the document data? 

Answer: In such cases the date of departure should be entered as the expiry date. 
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A1 CHANGE RECORD 


The following table lists the changes in each version of the document starting with 
version 4. 


Version 

Change Description 

Location 

4 

e-Borders replaced with Trusted Borders. Paragraph wording amended 

1 

ARINC, GHA, NBTC and STA added to table 1 

1.1 

“Primarily” deleted 

1.2 

Wording amended, e-Borders Operation Centre replaced with NBTC 

2.2.2 

Answer to 2.3.6 extended to cover requests for time window extensions 

2.3.6 

“Function” removed as last word of answer 

2.3.8/2.3.9 

Question and Answer rewritten to clarify the required situation 

2.3.9 

Clarification on the use of STD and STA 

2.3.11 

Clarification on how and when STD should be updated in messages 

2.3.12 

Clarification on how to report non-standard Travel Documents 

2.3.13 

Update to proposed changes to CTA legislation 

2.6.2 

2.6.3 

JBOC changed to NBTC 

2.8.1 

Wording changed to clarify reference is to LOC codes, not IATA/ICAO. 

3.5.9 

Clarification on codes to report in PAXLST UNB and UNG segments 

4.1.7 

Clarification on how to report Group Travel Documents such as NATO 
Travel Orders. 

4.2.4 

Clarification on how to report Travel Documents which have expired 

4.4.6 
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